The compiled Python extension in the wheel was called `_portable_lib`. That name
is misleading in two ways. "Portable" is the name of a kernel set in this project,
the portable kernels, and this file does not contain them: it holds the Python
bindings for the runtime. "Lib" says nothing, since every shared object is a
library. Someone looking for the portable kernels finds the Python bindings
instead, and someone looking for the bindings has no reason to open a file named
after kernels.

Rename it to `_C`, which is the usual name for a package's compiled C extension
and what PyTorch calls the same thing (`torch/_C.cpython-*.so`). The package path
already says `pybindings`, as in `executorch.extension.pybindings`, so a name like
`_pybindings` would repeat itself while `_C` reads as "this package's C
extension".

Nothing user facing changes. Applications import the public wrapper:

```python
from executorch.extension.pybindings import portable_lib
```

That wrapper re-exports everything from the compiled module and keeps its name, so
existing code continues to work. Only the private module behind it is renamed, and
it was already documented as experimental and subject to change.

Test plan:

Built a wheel and confirmed the shipped file is named for the new module:

```
extension/pybindings/_C.cpython-312-x86_64-linux-gnu.so
```

Installed that wheel into a fresh environment and checked both the public wrapper
and the private module load, then exported and ran a model through the Python
bindings:

```
public wrapper works: True
module name         : executorch.extension.pybindings._C
exported symbols    : 22
```

Also grepped the tree to confirm no build file, test, or comment still names the
old module.

ghstack-source-id: 20f23fe
ghstack-comment-id: 5282557165
Pull-Request: #21816

The compiled Python extension in the wheel was called `_portable_lib`. That name
is misleading in two ways. "Portable" is the name of a kernel set in this project,
the portable kernels, and this file does not contain them: it holds the Python
bindings for the runtime. "Lib" says nothing, since every shared object is a
library. Someone looking for the portable kernels finds the Python bindings
instead, and someone looking for the bindings has no reason to open a file named
after kernels.

Rename it to `_C`, which is the usual name for a package's compiled C extension
and what PyTorch calls the same thing (`torch/_C.cpython-*.so`). The package path
already says `pybindings`, as in `executorch.extension.pybindings`, so a name like
`_pybindings` would repeat itself while `_C` reads as "this package's C
extension".

Nothing user facing changes. Applications import the public wrapper:

```python
from executorch.extension.pybindings import portable_lib
```

That wrapper re-exports everything from the compiled module and keeps its name, so
existing code continues to work. Only the private module behind it is renamed, and
it was already documented as experimental and subject to change.

Test plan:

Built a wheel and confirmed the shipped file is named for the new module:

```
extension/pybindings/_C.cpython-312-x86_64-linux-gnu.so
```

Installed that wheel into a fresh environment and checked both the public wrapper
and the private module load, then exported and ran a model through the Python
bindings:

```
public wrapper works: True
module name         : executorch.extension.pybindings._C
exported symbols    : 22
```

Also grepped the tree to confirm no build file, test, or comment still names the
old module.

ghstack-source-id: 5386d2f
ghstack-comment-id: 5282557165
Pull-Request: #21816

The compiled Python extension in the wheel was called `_portable_lib`. That name
is misleading in two ways. "Portable" is the name of a kernel set in this project,
the portable kernels, and this file does not contain them: it holds the Python
bindings for the runtime. "Lib" says nothing, since every shared object is a
library. Someone looking for the portable kernels finds the Python bindings
instead, and someone looking for the bindings has no reason to open a file named
after kernels.

Rename it to `_C`, which is the usual name for a package's compiled C extension
and what PyTorch calls the same thing (`torch/_C.cpython-*.so`). The package path
already says `pybindings`, as in `executorch.extension.pybindings`, so a name like
`_pybindings` would repeat itself while `_C` reads as "this package's C
extension".

Nothing user facing changes. Applications import the public wrapper:

```python
from executorch.extension.pybindings import portable_lib
```

That wrapper re-exports everything from the compiled module and keeps its name, so
existing code continues to work. Only the private module behind it is renamed, and
it was already documented as experimental and subject to change.

Test plan:

Built a wheel and confirmed the shipped file is named for the new module:

```
extension/pybindings/_C.cpython-312-x86_64-linux-gnu.so
```

Installed that wheel into a fresh environment and checked both the public wrapper
and the private module load, then exported and ran a model through the Python
bindings:

```
public wrapper works: True
module name         : executorch.extension.pybindings._C
exported symbols    : 22
```

Also grepped the tree to confirm no build file, test, or comment still names the
old module.

ghstack-source-id: e6925ec
ghstack-comment-id: 5282557165
Pull-Request: #21816